U.S. patent applications Ser. No. 09/239,693, filed Jan. 29, 1999, entitled System and Method for Managing Security Objects; Ser. No. 09/240,718, filed Jan. 29, 1999, entitled xe2x80x9cSystem and Method for Dynamic Macro Placement of IP Connection Filtersxe2x80x9d; S/N 09/239,694, filed Jan. 29, 1999, entitled xe2x80x9cSystem and Method for Dynamic Micro Placement of IP Connection Filtersxe2x80x9d; S/N 09/240,483, filed Jan. 29, 1999, entitled xe2x80x9cSystem and Method for Central Management of Connections in a Virtual Private Network, and S/N 09/578215, filed May 23, 2000, entitled xe2x80x9cSystem and Method for Network Address Translation Integration with IP Securityxe2x80x9d, assignee docket END9 1999 0129 US1 are assigned to the same assignee hereof and contain subject matter related, in certain respects, to the subject matter of the present application. The above-identified patent applications are incorporated herein by reference.
This invention pertains to security over virtual private network (VPN) connections. More particularly, it relates to VPN NAT, or concurrent use of network address translation (NAT) and Internet Protocol (IP) Security (IPSec) protocols.
Virtual Private Networks (VPNs) are an active area of technical development throughout the Internet and computing industry. This is because they are a fundamental enabler for most forms of e-business. VPNs use protocol tunneling and encryption and decryption technology (IP Security protocols) to allow clients and servers, branch offices, or independent organizations to exploit the Internet for their TCP/IP traffic at much lower costs than buying dedicated lines, without losing a key benefit of dedicated lines: privacy.
The tunneling that VPN employs has a side effect, which creates a problem: two subnets or companies, or other users, which didn""t initially communicate directly, now do, and this greatly increases the likelihood of IP address conflicts.
Network Address Translation (NAT) is widely deployed in Internet and in companies connecting to the Internet to overcome address conflicts. These conflicts commonly occur between designated xe2x80x98privatexe2x80x99 address spaces (e.g. 10.*.*.*).
However, NAT and IP Security (IP Sec) are architecturally conflicting. In fact, NAT breaks IP Sec. That is, NAT xe2x80x9cis the feature which finally breaks the semantic overload of the IP address as both a locator and the end-point identifierxe2x80x9d (see, xe2x80x9cArchitectural Implications of NATxe2x80x9d, draft-iab-nat-implications-00, txt, March 1998. IPSec is described in Kent, S., and Atkinson, xe2x80x9cSecurity Architecture for the Internet Protocolxe2x80x9d, RFC2401, November 1998; Kent, S., and Atkinson, xe2x80x9cIP Authentication Protocolxe2x80x9d, RFC 2402, November 1998; and Kent, S., and Atkinson, xe2x80x9cIP Encapsulation Security Payloadxe2x80x9d, RFC 2406, November 1998.) As a result, two hosts cannot establish an IP Sec connection if there is a NAT system in between. There are two reasons why: the IP traffic that flows between the two hosts (for the IP Sec connection) will have authentication protocol (AH) or encapsulation security payload (ESP) applied. (See RFC""s 2402 and 2406, supra.)
First, with respect to ESP in tunnel mode, the IP address that needs to be translated is inside the ESP tunnel and is encrypted. It is, therefore, unavailable to NAT. With respect to authentication protocol (AH) in transport or tunnel mode, the IP address that needs to be translated is visible in NAT, but the AH authentication includes it. Therefore, changing the IP address will break the authentication at the remote end of the IP Sec connection. With respect to ESP in transport mode, even if ESP is used with authentication, the IP address is available to NAT. But, if the IP address is changed, the IP Sec connection breaks due to the breaking of authentication at the remote end of the IP Sec connection.
Second, even if the IP traffic for the IP Sec connection could be translated, it would fail because the IP Sec connection is based on Security Associations which contain the two host IP addresses. These are fundamental to the Security Association architecture (see RFC 2401, supra), in that the inbound IP Sec, on the host where decrypting (or authentication) is to occur, must be uniquely determined by the triple:
{destination IP addr, SPI, IP Sec protocol}.
where SPI is the security protocol index (see, RFC 2401, supra).
For example, given hosts A and W, assume NAT is applied to an IP datagram (a generic term for bytes that go on the wire) with ESP in transport mode that is going from A to W. Hence the IP source address is changed. Upon arrival at W, the packet will probably be decrypted successfully since that doesn""t depend on IP source address (which was in plaintextxe2x80x94not tunneled). If strictly implemented however, the inbound SPD checking which should follow decrypting will fail, due to the changed IP source address (because it was not the address used to negotiate the security association). So, even the transport mode ESP case fails.
Simply making NAT and IP Sec mutually exclusive is not the solution sought by the art. NAT is being deployed widely because it solves many problems, such as: masks global address changes, lowers address utilization, lowers Internet service provider (ISP) support burden, and allows load sharing as virtual hosts.
Yet, NAT is viewed as the greatest single threat to security integration being deployed in the Internet today. This xe2x80x9cNAT problemxe2x80x9d, as it is invariably termed, is architecturally fundamental. Also, legacy applications and services (for example, those developed for IP version 4) will continue to a long co-existence as applications and services develop for IP version 6. Consequently, there is a great need in the art for providing NAT and IP Sec coexistence, at least in selected situations, and to do so without introducing serious configuration problems. (IP version 4 is described in xe2x80x9cInternet Protocolxe2x80x9d, RFC791, September 1981. IP version 6 is described in Deering, S., Hinden, R., xe2x80x9cInternet Protocol, Version 6 (IPv6) Specificationxe2x80x9d, RFC2460, December 1998.)
A VPN connection between two address domains can have the effect of directly connecting two domains which most likely will not have been planned to be connected. Hence increased use of VPNs is likely to increase address conflicts. It is also understood that VPNs redefine network visibility and increase the likelihood of address collision when traversing NATs. Address management in the hidden space behind NATs will become a significant burden. There is, therefore, a need in the art to ameliorate that burden.
In U.S. patent application Ser. No. 09/240,720, a solution to the general problem of integrating IP Sec and NAT is presented. IP security is provided in a virtual private network using network address translation (NAT) by performing one or a combination of the four types of VPN NAT. (The description of three types of VPN NAT from assignee docket END9 1999 0129 US1 is included hereafter, and the fourth is the subject of this application.) This involves dynamically generating NAT rules and associating them with the manual or dynamically generated Internet key exchange (IKE) Security Associations, before beginning IP security that uses the Security Associations. (See, Harkins, D., Carrel, D., xe2x80x9cThe Internet Key Exchange (IKE)xe2x80x9d, RFC2409, November 1998. Security Associations is a term defined in RFC201, supra.) Then, as IP Sec is performed on outbound and inbound datagrams, the NAT function is also performed. By xe2x80x9cperform IP Secxe2x80x9d, is meant to execute the steps that comprise IP Sec outbound or inbound processing, as defined by the three IP Sec RFCs (and others) above. By xe2x80x9cperform NATxe2x80x9d, is meant to execute the steps that comprise the VPN NAT processing hereafter described in this application.
In U.S. patent application Ser. No. 09/240,720, the customer must configure each separate VPN NAT rule as a separate VPN connection. This is time consuming and prone to error, and VPN connections are really meant to protect the traffic and should be independent of specific VPN NAT rules. That is, the rules have heretofore been one to onexe2x80x94NAT thus increases the number of VPN connections required.
It is an object of the invention to provide an improved and greatly simplified system and method for concurrently implementing both Network Address Translation (NAT) and IP Security (IP Sec).
It is a further object of the invention to provide a system and method for solving the increased likelihood of IP address conflicts inherent in the use of a virtual private network (VPN).
It is a further object of the invention to provide a system and method for enabling utilization of VPNs without requiring re-addressing a domain (an expensive alternative).
It is a further object of the invention to provide a system and method for VPN NAT which can be accomplished entirely in the IP Sec gateway without requiring changes in domain hosts.
It is a further object of the invention to provide a system and method for VPN NAT which requires no, or only minor, changes to routing in each connected domain.
It is a further object of the invention to provide a system and method for VPN NAT which is simple to configure.
It is a further object of the invention to provide a solution to the address collision problems caused by VPNs.
It is a further object of the invention to provide a simplified solution for customer configuration of VPN connections.
It is a further object of the invention to allow a single VPN connection to support multiple VPN NAT rules.
It is a further object of the invention to provide a system and method which, on a system wide basis, avoids conflict among the implicitly, or dynamically assigned, VPN NAT rules.
It is a further object of the invention to provide a system and method which reduces system overhead for dynamic NAT rules by eliminating the need to manage numerous separate VPN connections for each NAT rule.
It is a further object of the invention to provide a VPN NAT system and method which simplifies network monitoring and traffic analysis.
In accordance with the invention, a system and method are provided for integrating network address translation within a secured virtual private network. An internal network host is configured to send selected traffic to a proxy network address. A virtual private network gateway is configured with a mapping table of network address translation rules. Responsive to the network address translation rules, a virtual private network connection is then started.
Other features and advantages of this invention will become apparent from the following detailed description of the presently preferred embodiment of the invention, taken in conjunction with the accompanying drawings.